Operating Systems and Application Patching Document
Introduction The operating system and application patching document will provide a standard operating procedure (SOP) for scheduling application maintenance and assessing impact of potential downtime and communicating planned outages or periods of limited availability. Overview The following are the objectives of the patching SOP document: # Identify required operating system and application patches, updates, fixes and service packs as part of regularly scheduled maintenance activities. # Assess impact and risk of planned operating system or application maintenance. # Identify periods of limited or no use for operating system and application maintenance. # Communicate to affected users, developers and administrators periods of limited or non availability. References The Nimble System operating system and application patching standard operating procedure The patch management simple risk assessment worksheet Table of Acronyms Document Distribution Receipt of this document without acknowledgement of review or modification will be assumed as concurrence. This document will be distributed to the following personnel: * System owner * Program managers * Line of service practitioners Document Organization This document is organized according to the standard process for identifying, scheduling and communicating required maintenance and periods of limited or non-availability. # Identify # Plan # Assess # Implement # Communicate Identify Identify what patches are required for designated managed servers. There are a number of tools and resources that may be used to identify necessary operating system and application patches by server. An example of this would be the Oracle CPU. Identify required patches typically by the following: * Host or system name: Affected host, server or system name. * Operating system and architecture: Windows Server Enterprise Edition x64 or Red Hat Enterprise Linux x86_64. * Application version and patch level: IBM Domino utility server version 9, Fix pack 5, Interim Fix 1 i.e. 9.5.1. * Location: Application location or file system. * Required patch to be implemented: patch number and download location. Other tools may also be used such as scanning, monitoring and remote management tools that may be capable of compiling a patching requirements report. The results of either processes may be compiled into a singular or comprehensive patch management schedule. An example would be the following: Plan The patch management plan may include planning detail for the remaining patch management lifecycle elements to include the following: # Risk assessment and impact analysis. # Implementation plan # Communication plan # Test plan # Post implementation assessment. Assess The impact and risk assessment shall identify risks associated with the patch management implementation, control measures to manage identified risks and the impact of the identified risks. Prior to scheduling a patch implementation, a patch management risk assessment may be conducted to determine the level of risk and what the expected outcome may be. The three key elements of the Patch Management Simple Risk Assessment are the following: # Probability: The likeliness of a failure. # Severity: The harshness or grievousness of the failure. # Risk Level: Assessed status or condition *See Attachment A: The patch management simple risk assessment worksheet. Or this may be part of a configuration management process or standard operating procedure. The risk assessment process must be followed by an impact analysis. The impact analysis will provide a process to determine who will be affected by the assessed risk and how can the business unit recover from the identified risk. The key elements of the impact assessment are: # Recovery point objective: The objective amount of time it will take to recover from failure. # Recovery time objective: The objective point in time that the system must be restored to. # Countermeasures: Control measures introduced to mitigate or reduce identified risks. # Affected business process or application: System, process or business affected by failure or outage. # Dependencies: System, resource or process that affected resource at risk depends on. # Sub-process: Systems or process that requires the resource at risk. # Tenants: Business unit that requires the resource at risk. * See Attachment B: The patch management simple impact assessment work sheet. When the risk has been assessed, the impact identified, control measures introduced and the patch management configuration change has been approved at the appropriate level an implementation plan shall be developed. Implementation The patch management implementation planning shall first identify an implementation window based on the availability of the system. Systems should establish a patch management implementation rhythm when possible. This allows for end users, managers and administrators to plan cyclically on a regular or monthly basis. For example, the organizational implementation window for patch management implementation may be the 2nd Tuesday of the month in a predominantly Microsoft server environment or even quarterly for a predominantly oracle application environment. The patch management implementation plan shall include the information from the patch management schedule in addition to the implementation date and window of availability. Certain business processes may dictate periods of limited availability. A financial institution may prefer a period closer to the end of the month in advance of an uptick in utilization at the beginning of the month. Communication The purpose of the simple communication plan outlines the communications intent and activities in support of the program. The communications plan should include the following: # Name of server and/or application # Time and date of window of non-availability. # Reason for period of non-availability # Follow up communication advising users that system is available A communication must be sent to all affected system users and managers when the implementation plan has been developed and approved. The communication shall include the name of the affected system, date and time of the planned outage and the outage window. An additional communication shall be sent when the system is made available back to the users, post patch implementation. Summary The operating system and application patching standard operating procedure has provided a document framework for Identifying and planning the implementation of system, application or component software maintenance. It also provides a method of identifying and assessing risk as part of the implementation planning process. We have also been provided a process of communicating system availability and our maintenance planning. The attached risk assessment and impact assessment provide functional tools for our deliberate planning process. [http://nimble.wikia.com/wiki/NIMBLE_Wikia << Home]